SPECIFICATION 
MULTICAST FALE TRANSMISSION METHOD 



BACKGROUND OF THE INVENTION 
The present invention relates to a method for multicasting a specified 
file to multiple destinations and, more particularly, to a method for multicasting 
the specified file to the multiple destinations via wireless links, such as a 
5 satellite communication circuit. 

As prior art of this technical field, there is proposed an MFTP 
(Multicast File Transmission Protocol) system in which a transmitting station 
multicasts a specified file composed of a plurality of blocks, then a receiving 
station requests retransmission of a DTU (Data Transmission Unit) that could 
10 not be received, so that the transmitting station retransmits the requested DTU, 
3 thus completing the file transfer (as published in Japanese Pat. Pub. Gazette No. 
I 512726/98). 

5 Fig. 28A depicts a data transmission packet format transmitted in the 

!*) MFTP system in a case where each file comprises blocks #1, #2, #3 and #4; 
15 each block is composed of frames #11 to #1N, and each frame including an 
ffi MFTP-OH, which is an OH (overhead) for use in the communication path 
b between a transmitting processor and a receiving processor in the MFTP 
U system, and an MFTP-OH (option) for optional use. Each frame including the 
MFTP-OH (option) constitutes one DTU. This DTU, the MFTP-OH, a UDP 
20 (User Datagram Protocol)-OH and an IP-OH, which is an overhead for IP 
(Internet Protocol), constitute one MTU (Multicast Transmission Unit). Fig. 
28B is a diagrammatic representation of a retransmission-requesting packet 
format in the MFTP system, which indicates received results for each bit in one 
DTU. In this example, each cross mark x indicates a result of non-reception. 
25 The conventional MFTP system adopts a method which, during 

multicast transmission of a file, receives from a plurality of receiving stations 
response signals which indicate DTUs to be retransmitted. In the MFTP 
system, since data errors are expressed in the form of a bit map, even where 
only one DTU is erroneous, it is necessary that the receiving station sends back 
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to the transmitting station a retransmission-requesting packet composed of a bit 
map (usually, of a size of one MTU (=1500 bytes)) corresponding to one block. 

The MFTP system is usually applied to a communication system, whose 
communication circuits from a plurality of receiving stations to a transmitting 
station (denoted as ct up-link direction") are dedicatedly allocated to 
communicate between an individual receiving station and the transmission 
station, such as conventional telephone circuits. However, since the total 
amount of data becomes large, the MFTP system has a serious drawback in 
terms of efficiency in retransmission processing on applying to a 
communication system, whose circuits in the up-link direction are shared on a 
multiple access basis, such as satellite communication circuit. 

SUMMARY OF THE INVENTION 

An object of the present invention is to provide a multicast file 
transmission method, which permits efficient multicast file transmission with 
high reliability even in the communication system, which uses in the up-link 
direction a specified transmission circuit, such as a multiple access satellite 
communication circuit. 

To attain the above object, the multicast file transmission method 
according to the present invention, comprising: 

transmitting a data file composed of a plurality of blocks from a sending 
side to respective receiving destinations; 

testing, at said respective destinations, whether or not any transmitted 
packet is found erroneous in the data file composed of a plurality of blocks 
after the end of said transmission of the data file; 

transmitting to said sending side from any of said receiving respective 
destinations, where any transmitted packet is found erroneous by said testing in 
the data file composed of a plurality of blocks after the end of said transmission 
of the data file, a request-for-retransmission signal for requesting 
retransmission of the transmitted packet of data found erroneous in said data 



file received at said any of respective receiving destinations, said 
request-for-retransmission signal being defined to indicate the offset position of 
said erroneous data in said transmitted packet of data and the data length of said 
erroneous data; and 

5 retransmitting the transmitted packet of data found erroneous from the 

sending side to said any of said respective receiving destinations in a 
multi-destination re-transmittal phase starting in response to said 
request- for-retransmission signal. 

The request-for-retransmission signal can be defined to send, for 
JLO example, a total of 8 bytes composed of 4 bytes representative of the offset 
tf? position of said transmission packet of said erroneous data and 4 bytes 
fii representative of the length of said erroneous data. 

E BRIEF DESCRIPTION OF THE DRAWINGS 

i - \ 

Sj The present invention will be described in details below with reference 

r4 5 to accompanying drawings, in which: 

ff Fig. 1 is a diagram illustrating a protocol stack for use in the present 

J{ invention; 

^ Fig. 2 is a diagram illustrating a sequence of an announce/registration 

phase for use in the present invention; 
20 Fig. 3 is a diagram illustrating a sequence of a multi-destination 

delivery phase for use in the present invention; 

Fig. 4 is a diagram illustrating a sequence of a multi-destination 
retransmission phase for use in the present invention; 

Fig. 5 is a diagram illustrating a sequence of an acknowledgement phase 
25 for use in the present invention; 

Fig. 6 is a diagram illustrating a basic packet format of an announce 
registration phase for use in the present invention; 

Fig. 7 is a diagram illustrating a basic packet format of the 
multi-destination delivery phase for use in the present invention; 
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Fig. 8 is a diagram illustrating a basic packet format of the 
multi-destination retransmission phase for use in the present invention; 

Fig. 9 is a diagram illustrating a basic packet format of the 
acknowledgement phase for use in the present invention; 
5 Fig. 10 is a diagram illustrating a header format for use in the present 

invention; 

Fig. 11 is a diagram explanatory of a definition of code Length for use 
in the present invention; 

Fig. 12 is a diagram illustrating a multi-destination delivery start 
1 0 announce packet format for use in the present invention; 
% Fig. 13 is a diagram illustrating a registration packet for use in the 

pi present invention; 

fj Fig. 14 is a diagram illustrating a format of a file data packet and a 

W multi-destination retransmission end packet for use in the present invention; 
|J Fig. 15 is a diagram illustrating each format of a multi-destination 

S delivery end packet and a multi-destination retransmission end packet for use in 
£3 the present invention; 

S Fig. 16 is a diagram illustrating each format of a multi-destination 

retransmission start packet and a multi-destination retransmission end packet 
20 for use in the present invention; 

Fig. 17 is a diagram illustrating each format of a retransmission request 
packet and a retransmission request end packet for use in the present invention; 

Fig. 18 is a diagram illustrating a format of an acknowledgement start 
packet for use in the present invention; 
25 Fig. 19 is a diagram illustrating a format of an acknowledgement 

answer packet for use in the present invention; 

Fig. 20 is a diagram illustrating a format of an acknowledgement end 
packet for use in the present invention; 

Figs. 21 A and 2 IB are diagrams illustrating a format of a data delivery 



packet and a format of a retransmission request packet, respectively, for use in 
the present invention; 

Fig. 22 is a flowchart of the sending side in an announce/registration 
and multi-destination delivery phase in the present invention; 

Fig. 23 is a flowchart of the receiving side in an announce/registration 
and multi-destination delivery phase in the present invention; 

Fig. 24 is a flowchart of the sending side in a retransmission phase in 
the present invention; 

Fig 25 is a flowchart of a receiving side in a retransmission phase in the 
present invention; 

Fig. 26 is a flowchart of a sending side in an acknowledgement phase in 
the present invention; 

Fig. 27 is a flowchart of a receiving side in an acknowledgement phase 
in the present invention; 

Fig. 28 is a diagram illustrating a format of a data delivery packet (a) 
and a format of a retransmission request packet (b) in a conventional method; 

Fig. 29 is a diagram illustrating, in comparison the present invention 
with a conventional method, relationships of the circuit error rates with respect 
to the transmission file size and the sum of the sizes of retransmission request 
packets at one receiving station; and 

Fig. 30 is a system diagram showing an example of a two-way 
communication service system using a communication satellite, which 
embodies the present invention. 

DETAILED DESCRIPTION 

The features of the present invention are summarized as follows: 
(I) Outlines of functional requirement for protocol 

® Transmission method: 

The transmission method used in the present invention is a limited 
delivery method (including acknowledgements), in which the sender performs 



confirmation of transmittal (hereinafter referred to "acknowledgement") for 
each of limited members who have been registered as "receivers" at the start of 
file transfer. 

(2) Method for acknowledgement: 

5 The acknowledgement is carried out after establishing respective 

connection routs from the sender to the receivers. A centralized supervisory 
system is used in which a server for multi-destination delivery performs the 
acknowledgement for all receivers (having been registered). 

(3) Transmission rate setting function: 

10 This is a function which enables the sender to set the multicast 

*G transmission rate, under consideration of the transmission rate (line speed) and 
f|i the number of receivers. 

p (D Destination folder specifying function: 

\l This is a function to specify a receiver's folder for storing the file to be 

^15 delivered. 

r? (D File's validity verifying function: 

O This is a function for verifying the validity of a file transmission by 

M performing a checksum testing on a packet-wise basis at the time of sending 

file data from the server to clients in a multi-destination delivery phase and a 
20 multi-destination retransmission phase. 

The above functions will be described below in more detail. 

(2) Protocol Stack 

Fig. 1 depicts a protocol stack of multicast file transfer software for 
implementing the present invention. 
25 (3) Communication Procedure 

The communication procedure is divided into: an 
"announce/registration phase" for delivering file transmission information; a 
"multi-destination delivery phase" for performing multi-destination delivery; a 
"multi-destination retransmission phase" for performing multi-destination 
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retransmission; and a "acknowledgement phase" for carrying out 
acknowledgement. In all of the announce/registration phase, the 
multi-destination delivery phase and the multi-destination retransmission phase, 
the data transmission from the server to the clients is performed along multicast 

5 UDP transmission. On the other hand, the data transmission from the clients 
to the server in the announce/registration phase, the multi-destination 
retransmission phase and the acknowledgement phase and the data transmission 
from the server to the clients in the acknowledgement phase are performed 
along a unicast UDP transmission. The respective sequences are shown in 

10 Figs. 2, 3, 4 and 5. 

2 0 Announce/registration phase: 

S With reference to Fig.2, the server is triggered by a request for the start 

2 of transmission to send a "multi-destination delivery start announce packet" 
H using a multicast EP address for announcement use. This packet includes, in 
l_5 addition to MF-common header information, the file name, the file size, the 
p transmission rate, a multicast IP address for multi-destination data transmission 
Q and port number information of the file to be sent. After sending the first 
U "multi-destination delivery start announce packet", the server sends the 
"multi-destination delivery start announce packet" at regular time intervals 
20 defined by a Ts4 timer. Having received a registration packet from each client 
belonging to a Group ID specified as the destination, or after a certain elapsed 
time (a Tsl timer), the server uses them as a transmission start trigger to shift 
into the multi-destination delivery phase. Further, the server draws up an 
acknowledgement list in accordance with the contents of the packets received 
25 during the registration- receiving period, and has its validity checked by an 
Application Program (AP) prior to the start of the multi-destination 
retransmission phase. 

The client receives a multi-destination transmission start announce 
packet and, if the client belongs into the Group ID, then after making an inquiry 
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to the AP, sends back to the server a "registration packet" carrying a result of 
the inquiry (a registration code), thereafter proceeding to the multi-destination 
delivery phase. Incidentally, when a time-out occurs in a Tc3 timer which 
defines an inter-packet time-length, the program ends. 
5 (2) Multi-destination delivery phase: 

With reference to Fig.3, the server responds to the transmission start 
trigger to send a "file data packet". The "file data packet" carries an offset 
position in the file, a checksum value of file data information in the packet and 
the file data information. Accordingly, even if the client happens to become 
10 unable to receive the "file data packet" halfway through its reception, the client 
can continue data reception. Upon completion of the data transmission, the 
fy server sends a "multi-destination delivery end packet' ' and, when the validation 
u of the acknowledgement list by the AP is already completed, the server 
r{ proceeds to the multi-destination retransmission phase. Incidentally, the "file 
%5 data packet" and the "multi-destination delivery end packet" are sent out via 
ffl different port numbers. 

O On detecting an omission of the file data during reception of the "file 

M data packet", the client draws up a list of data to be requested for 
retransmission. Upon each reception of the "file data packet" the client 

20 calculates the checksum value of the file data received and compares it with the 
checksum value calculated by the server. If a mismatch is found between the 
checksum values, then the client draws up the list of data to be requested for 
retransmission. The client proceeds to the multi-destination retransmission 
phase after receiving the "multi-destination delivery end packet". Upon 

25 time-out of Tc3, the program ends. 

CD Multi-destination retransmission phase: 

With reference to Fig. 4, after receiving the "multi-destination delivery 
end packet" or a "multi-destination retransmission end packet", the server waits 
for a "retransmission requesting packet" and a "retransmission request end 

8 



packet" from the client until time-out of a Ts2 timer. After time-out of the Ts2 
timer, or after receiving the "retransmission request (end) packet" from each 
client registered in the acknowledgement list, the server draws up 
retransmission data lists based on omitted-data lists received from the clients, 
5 and sends out the "multi-destination retransmission start packet' 5 and the 
"multi-destination retransmission data packet" to the same multicast addresses 
as in the multi-destination delivery phase. The multi-destination 
retransmission phases are repeated a maximum of N2 times until the 
omitted-data lists of all registered receivers in the acknowledgement list 
10 becomes empty or until a time-out of the Ts2 timer occurs. Upon completion 
m of the multi-destination retransmission phase, the server proceeds to the 
fy acknowledgement phase. As is the case with the multi-destination delivery 
P phase, different port numbers are used to send out the "multi-destination 
J! retransmission data packet" and the "multi-destination retransmission end 
15 packet". 

® Upon detecting an omission of file data, each client draws up a list of 

D data to be requested for retransmission as in the multi-destination delivery 
M phase. Further, as is the case with the multi-destination delivery phase, the 
client mutually compares for each packet the checksum values calculated by 
20 the server and the client, and if a mismatch is found, prepares a list of data to be 
requested for retransmission. After receiving the "multi-destination delivery 
end packet" or "multi-destination retransmission end packet" the client sends 
out a "retransmission request packet" and a "retransmission request end packet" 
to the server. When no omission of the file data is detected, the client sends 
25 out a "retransmission request end packet" composed of only a common header 
portion. Upon receiving an "acknowledgement start packet", the client 
proceeds to the acknowledgement phase. The program ends when time-out of 
Tc3 occurs. 

(D Acknowledgement phase: 
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This is described with reference to Fig. 5. To ensure reliability in the 
file transfer, the server makes a check to see if its specified file has been sent 
out to all the clients registered in the acknowledgement list. 

Upon receiving an "acknowledgement start packet", each client sends 
5 back an "acknowledgement answering packet" containing the result of 
confirmation. Incidentally, the program ends upon occurrence of Tc3 
time-out. 

(4) Packet format 

Fig. 6 shows a basic packet format in the announce/registration phase; 
10 Fig. 7 shows a basic packet format in the multi-destination delivery phase; Fig. 
8 shows a basic packet format in the multi-destination retransmission phase; 
and Fig. 9 shows a basic packet format in the acknowledgement phase. 

(5) Common header 
A detailed description will be given of each field of the common header 

£5 (MF header) portion. 
W ® Version: 

b This has one-byte-length and is used to identify the version of the 

£ protocol. 

(2) Control: 

20 This has one-byte-length and is used to identify the packet shown in 

Table 1. 
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Table 1 

Control Field (Classification of Packet) 
Multi-destination delivery start announce packet 



Registration packet 



File data packet 



Multi-destination delivery end packet 



Multi-destination retransmission start packet 



Multi-destination retransmission end packet 



Retransmission request packet 



Retransmission request end packet 



Multi-destination retransmission data packet 



Acknowledgement start packet 



Acknowledgement answer packet 



Acknowledgement end packet 



Inter-user information packet 
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© StnED: 

Stn ID has four-byte-length and is an identifier for specifying the sender 
of the packet. 

(D Group ID: 

5 Group ID has four-byte-length and is employed as an identifier to 

specify the group of receivers. 
© Ref ID: 

Ref ID is an identifier for identifying each packet from the start to end 
of the file transfer, and is a two-byte-length number for preventing duplication 
10 of servers. All packets from the start to end of one transfer of any file have 
£ the same Ref ID to distinguish from packets of other file transfers. Ref ID has 
m two-byte-length, and hence it can be used 65535 times for transfer of files 
C without duplication, but it is used after being reset under an agreement between 
J; the sender and the receiver. Since Ref ID is used to distinguish among file 
%5 transfers, it is possible to transfer plural files at the same time. When plural 
P senders are present in the same multicast environment, it is necessary to 
O predetermine the range of Ref ID which can be used by each sender. 
5 (D Length: 

Length has a two-byte-length field indicating the length of each packet, 
20 that is, indicating the length of information section as depicted in Fig. 11. 
(6) Kinds of packets and their formats 

GD Multi-destination delivery start announce packet: 
In an announce/registration phase the server sends out this packet. The 
packet format is shown in Fig. 12. This packet is used as a signal for 
25 indicating the start of the multi-destination delivery. The server periodically 
sends this packet at regular intervals defined by a Ts4 timer during the 
announce/registration phase. Based on this packet received first, the client 
brings Ref ID into correspondence with the multicast address, which are the 
port number, the transmission rate, the file size and the file name of the "file 



data packets", received in the multi-destination delivery phase. 
(D Registration packet: 

In the announce/registration phase the client sends out this packet. Its 
packet format is depicted in Fig. 13. This packet is identical in format with 
5 the "multi-destination delivery start announce packet" except that the Stn ID of 
the client is adopted as Stn ID in the common header portion. The client uses 
this packet to indicate the reception of a file to the server. 

The server detects from its received "registration packets" the receivers 
to be acknowledged, and prepares an acknowledgement list. After the 
10 time-out of a Tsl timer, or after receiving the "registration packets" from the 
yp clients belonging to Group ID specified as the destination, the server starts the 

s.!fs 

nj multi-destination delivery phase. 
2 (3) File data packet: 

^ In the multi-destination delivery phase the server sends out this packet. 

15 The packet format is depicted in Fig. 14. This packet contains binary data of 
£0 the file to be transferred and the sequence number used as offset value 
0 indicating the position of data in the file, and a checksum value of binary data 
^ calculated by the server. The sequence number has four-byte-length, and is an 
offset value indicating the position where the data being carried by the packet 
20 occupies in the file, the offset value being expressed on a byte-wise basis. 
The client reconstructs the file from the sequence number and the length value 
in this packet. When an omission of received data is caused by a packet error 
or loss, the client makes up a retransmission request data list composed of the 
offset value (the sequence number) of the omitted data and the length value of 
25 the omitted data. 

Further, the client compares the checksum value sent thereto with the 
checksum value calculated from its received binary data, deciding whether the 
packet-wise data transfer is successful or not. When a failure in the data 
transfer is found by the checksum inspection, the client adds the offset value 
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and length value of the data concerned to the retransmission request data list. 
(D Multi-destination delivery end packet: 

The server sends out this packet in the multi-destination delivery phase. 
The packet format is shown in Fig. 15. Upon completion of the transmission 
5 of all pieces of data, the server sends out this packet as a signal for indicating 
the start of the multi-destination retransmission phase and starts a Ts2 timer. 

The server keeps on sending the "multi-destination delivery end packet" 
at regular time intervals defined by a Ts 5 timer until receiving the 
"retransmission request end packet' 5 from each receiver registered in the 
XO acknowledgement list or until time-out of the Ts2 timer occurs. 
® Upon first reception of this packet, the client proceeds to the 

|J multi-destination retransmission phase on the assumption that the multicast 
M data transmission has terminated. Upon receiving this packet, the client sends 

i * ; 

%j back a "retransmission request end packet" to the server 
f§ 5 (5) Multi-destination retransmission start packet: 

jT The server sends out this packet in the multi-destination retransmission 

phase. The packet format is shown in Fig. 16. Upon occurrence of time-out 

M of the Ts2 timer, or after receiving a "multi-destination (retransmission) end 
packet" from each client registered in the acknowledgement list, the server 

20 sends out the "multi-destination retransmission start packet" and starts to send 
out "multi-destination retransmission data packets". 

The client interprets the reception of this packet as a signal for 
indicating the start of the multicast retransmission. 

(D Multi-destination retransmission end packet: 

25 The server sends out this packet in the multi-destination retransmission 

phase. The packet format is the same as that of the "multi-destination 
retransmission start packet" depicted in Fig. 16. After sending out all 
"multi-destination retransmission data packets", the server sends out this packet 
to indicate the end of the multi-destination retransmission phase to each client, 
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and starts the Ts2 timer. 

The server keeps on sending this packet at regular time intervals defined 
by the Ts 5 timer after time-out of the timer Ts2, or until receiving a 
"retransmission request end packet" from each client registered on the 
5 acknowledgement list. 

Upon receiving this packet, the client sends back the "retransmission 
request packet" and the "retransmission request end packet" to the server. 

CD Retransmission request packet, retransmission request end packet: 
The "retransmission request packet" is sent back from each client in the 
10 multi-destination retransmission phase. The packet format is shown in Fig. 17. 
ffl This packet is used to request the retransmission of data which the client could 
fU not receive in the multi-destination delivery or retransmission phase. 
■M= The client sends to the server a set of (offset value + data length) of 

sj omitted data on the basis of the retransmission request data list prepared by the 
%6 client. A plurality of (offset value + data length) may be contained in this 
U Packet. 

g After receiving the "multi-destination delivery (retransmission) end 

^ packet", the server accepts this packet from each client until time-out of the Ts2 
timer, and draws up a retransmission request list on the basis of the information 
20 of this packet. 

In a case where an amount of retransmission-requested data is so large 
that the "retransmission request packet" is composed of a plurality of packets, 
each client sends back to the server the first to penultimate packets as 
"retransmission request packets" and the last packet as the "retransmission 
25 request end packet". When the omitted data can be accommodated in one 
packet, the client sends back only the "retransmission request end packet". 
(8) Multi-destination retransmission data packet: 
The server sends out this packet in the multi-destination retransmission 
phase. The packet format is the same as that of the "file data packet" shown 
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in Fig, 14. Based on the retransmission request list, the server makes up and 
sends out this packet. Each client uses this packet to complement the omitted 
data. 

(§) Acknowledgement start packet: 
5 In the acknowledgement phase the server sends this packet to each 

client to demand it to confirm the reception of the data file intended to deliver, 
and starts a timer Ts3. 

The server keeps on sending the acknowledgement start packet at 
regular time intervals defined by time-out of a Ts6 timer until receiving 
10 acknowledgement answer packets from all the receivers registered in the 
y[3 acknowledgement list, or until time-out of the timer Ts3 occurs. The packet 
fU format of this packet is shown in Fig. 18. 

tl Upon reception of this packet, each client enters the acknowledgement 

phase. The client sends back to the server the "acknowledgement answer 
P15 packet" containing an answer code. 
~j ® Acknowledgement start(answer) packet: 

O In response to the "acknowledgement start packet" at the 

M acknowledgement phase, each client sends back this packet to the server. The 

packet format is shown in Fig. 19. 
20 © Acknowledgement end packet: 

Upon receiving the acknowledgement answer packet from each client, 

or upon occurrence of time-out of the Ts3 timer, the server sends out this packet. 

That packet format is shown in Fig. 20. 

(7) Timers 

25 The timer of each client is designated by TcY and the timer of the server 

by TsX. 

TcY is a numerical value which each client calculates by a certain 
algorithm after receiving the multi-destination delivery start announce packet. 
On the other hand, TsX is a numerical value which is set by AP and handed to 
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the server 

® Tc3 timer: 

The Tc3 timer is one that is provided on the part of each client, and it is 
used to ensure completion of the file transfer started by the "multi-destination 
5 delivery start announce packet". This timer re-starts each time the client 
receives an appropriate packet in each phase. And this timer stops when the 
client receives the next appropriate packet. The client terminates the program 
upon occurrence of time-out of the Tc3 timer. 

<D Tsl timer: 

10 The Tsl timer is to set the time for the server to accept the "registration 

m packet" in the announce/registration phase. When this Tsl timer times out, 
fu the server stops to accept the registration packet, and draws up a receiver list 
p and transfers it to AP. 
rj (§) Ts2 timer: 

%$ This Ts2 timer is used at the side of the server to define a waiting time 

for the "retransmission request end packet" from the sending-out time of the 

C "multi-destination delivery end packet" or the "retransmission request end 

H packet". When this Ts2 timer times out ? the server starts the next 
multi-destination retransmission phase. 

20 <D Ts3 timer: 

The Ts3 timer is used by the server in the acknowledgement phase and 
is started upon sending the first "acknowledgement start packet". This Ts3 
timer defines a waiting time for the "acknowledgement answer packet", and 
stops when the server receives the "acknowledgement answer packet" from all 

25 the clients registered in the acknowledgement list. In a case where there is a 
client which does not send back the "acknowledgement answer packet" even 
after the time-out of the Ts3 timer, that client is recorded as an 
acknowledgement failure on a server log. 
(D Ts4 timer: 
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The Ts4 timer defines the time intervals at which the "multi-destination 
start announce packets" are delivered. The server delivers the 
"multi-destination delivery start announce packet" at the time intervals defined 
by the Ts4 timer until the Tsl timer times out. 
5 ® Ts5 timer: 

The Ts5 timer defines the time intervals at which the "multi-destination 
delivery (retransmission) end packet" is delivered. The server keeps on 
delivering the "multi-destination delivery (retransmission) end packet" at the 
time intervals defined by the Ts5 timer until receiving the "retransmission 

10 request packets" from all the clients registered in the acknowledgement list, or 

O 

y3 until the Ts2 timer times out. 
fy CD Ts6 timer: 

C The Ts6 timer defines the time intervals at which the 

JrJ "acknowledgement start packet" is delivered. The server keeps on delivering 
J^S the "acknowledgement start packet" at the time intervals defined by the Ts6 
JB timer until receiving the "acknowledgement answer packets" from all the 
O clients registered in the receiver list, or until the Ts3 timer times out. 
S (8) N2 

N2 defines the number of repeating cycles of the multi-destination 

20 retransmission phases. 

(9) Method for starting acknowledgement procedure 

The server sends out the "acknowledgement start packet", and waits for 
the lapse of a time defined by the Ts3 timer or for sending back of the 
"acknowledgement answer packets" from all the receivers registered in the 

25 acknowledgement list. When "acknowledgement answer packets" are not sent 
back from all the registered receivers even after a certain elapsed time defined 
by the Ts6 timer, the server re-sends out the "acknowledgement start packet". 
As for a client station which does not send back the "acknowledgement answer 
packet" even after the time-out of the Ts3 timer, an acknowledgement failure is 
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recorded on the log. 

An actual method to implement the present invention will be described 
hereinafter based on the functions described above. 

Fig. 21 A illustrates the data delivery packet format for use in the 
5 multicast file transmission method (also referred to as "MSAT system" ) 
according to the present invention. The file is shown to comprise blocks #1, 
#2, #3 and #4, and the blocks #1 to #4 are each added with an MSAT-OH 
which is an OH (overhead) for use in communications between transmitting 
and receiving processors of an MSAT system. Each frame containing this 
10 MSAT-OH further contains the UDP (User Datagram Protocol)-OH and the 
i DP-OH which is an OH for IP (Internet Protocol). The MSAT-OH is 
$u composed of a control signal "Control", a station identification signal "Stn ID", 
ft a group identification signal Group ID, a block identification signal Ref ID, and 
y a block length "Length". 

*J5 Fig. 2 IB illustrates the retransmission request (end) packet format of 

60 the MSAT system, and the unit of the retransmission request is composed of the 

O sequence number indicating the offset position (4 bytes) and the data length (4 

Q 

C bytes), that is, a total of 8 bytes. Accordingly, in a case of a single error, a 
retransmission request can be made with a small number of bytes. 

20 [Embodiments] 

A description will be given below of the operation for the method of the 
present invention. 

Fig. 22 is a flowchart, showing operations at sending side in the 
announce/registration/multi-destination delivery phase and the 
25 multi-destination delivery phase, which is explanatory of the start of data 
transmission. 

In this instance, after the start of operation (S 0 )> Tsl timer and Ts4 timer 
are started and the "multi-destination delivery start announce packet" are 
transmitted (Si), and a check is made to see if a "registration packet" has been 
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received (S2) from each receiver. If the result of this check (S 2 ) is YES, the 
receiver is added to an acknowledgement list (S3), and when the result of the 
check (S 2 ) is NO or when the check result YES is added to the 
"acknowledgement list", a check is made to determine if the Tsl timer has 
5 timed out (S 4 ). When the result of this check (S4) is YES, a test is made 
whether or not an "acknowledgement list" is prepared (S5). When the result 
of this test (S 5 ) is YES, the file data is divided to provide packets (S 6 ), which 
are followed by transmission of the "multi-destination delivery end packet" 
after the multi-destination delivery of the "file data packet" (S 7 ), and then the 
10 procedure proceeds to the operation of the retransmission phase 0&1). In step 
Ci S4, when the check result is NO indicating that the Tsl timer has not timed out, 
fy a check is made to see if the Ts4 timer has timed out (S10). When the result of 
2 this check (S10) is YES, the Ts4 timer is restarted and the "multi-destination 
!y delivery start announce packet is transmitted (Sn), and when the result of the 
*L5 check (Sio) is NO, the procedure goes back to step (S2) in which to make a 
check to see if the "registration packet" has been received from any of the 

£=4= 

O receivers. When the result of the check S 5 is NO indicating that no 

U "acknowledgement list" is not generated, the procedure ends (S 9 ). 

Fig, 23 is a flowchart showing the operations at the receiving side in the 

20 announce/registration/multi-destination delivery phase. 

In this instance, after the start of operation (R 0 ), a check is made to see 
if the "multi-destination delivery announce packet" is received (Ri), and when 
the result of this check (Ri) is YES, the "registration packet" is sent out (R 2 ) 
and the Tc3 timer is started (R 3 ), and a check is made to see if the Tc3 timer 

25 has timed out (R4). If the result of this check (R4) is YES, this phase ends (R5). 
When the result of the check (R4) is NO, a check is made to see if the "file data 
packet" has been received (R<$X and when the check result of the step (R$) is 
YES, a check is made to see if the "file data packet" is normal (R 7 ). When the 
check result of the step (R 7 ) is YES, the contents of the "file data packet" are 
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stored in a memory and the Tc3 timer is restarted (R$ a ). When the check result 
of the step (R 7 ) is NO, a retransmission request data list is prepared and the Tc3 
timer is restarted (Rgb). As mentioned above, when Tc3 timer is restarted or 
when the check result of the step (R^) is NO, a check is made to determine 
5 whether or not the "multi-destination delivery end packet" has been received 
(R 9 ). When the check result (R 9 ) is YES, the procedure is shifted to a 
retransmission phase (SKlO), while when the check result (R 9 ) is NO, the 
procedure goes back to step (R 5 ). 

Fig. 24 is a flowchart showing operations at the sending side in the 
10 retransmission phase. 

5 In this instance, when the operation of the retransmission phase is 

m started (Sg), a Ts2 timer and a Ts5 timer are started (Si 2 ). Then a check is 
2 made to see if the "retransmission request packet" or the "retransmission 
!J request packet" has been received (S i3 ). In a case where the result of this 
p[5 check (S 13 ) is YES, when the receiver is added to a "retransmission request list" 
© (Sh), or when the result of the check (Si 3 ) is NO, a check is made to determine 
O whether or not the Ts2 timer has timed out (S15). If the result of this check 
M (S15) is YES, "multi-destination retransmission data packets" are 
multi-destination delivered on the base of the retransmission request list (S^), 
20 and then a check is made to see if the retransmission count is in excess of a 
preset value of N2 (Si 7). If the result of this check (S17) is YES, the sending 
side proceeds to the operation of the "acknowledgement phase" (*2) (S 2 i). In 
a case where the result of the check (S17) is NO, when a counter (referred to 
"retransmission counter") for counting the number of retransmission times is 
25 counted up and the Ts5 timer is restarted (Sig), or when the result of the check 
(S15) is NO, a check is made to see if the Ts5 timer has timed out (Si 9 ). When 
the result of this check (Si 9 ) is YES, or when the result of this check (S i9 ) is NO 
while the Ts5 timer is restarted and the "multi-destination retransmission end 
packet" (S 2 o) is sent out, the procedure goes back to step Si 3 . 
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Fig. 25 is a flowchart illustrating operations at the receiving side in the 
retransmission phase. 

In this instance, upon starting the operation (810) of the retransmission 
phase (Rio), a check is made to see if there is prepared the "retransmission 
5 request data list" (Rn), and if the result of this check (Rn) is NO, the receiving 
side sends out a "retransmission request end packet" (Ri 2 ), and proceeds to 
the operation (820) of the "acknowledgement phase" (R B ). When the result 
of the check at the step (Rn) is YES, the "retransmission request packet" and 
the "retransmission request end packet" is sent out (R M ), and a check is made to 
1 0 see if the multi-destination retransmission start packet" has been received (Ri 5 ). 
5 When the result of this check at the step (R 1S ) is YES, the Tc3 timer is restarted 
S (Ri 6 ) and a check is made to see if the Tc3 timer has timed out (Rn); when the 
J° result of this check at the step (R n ) is YES, the operation (810) of this 
W retransmission phase ends (Rn). When a result of the check at the step (Ri 5 ) is 
15 NO, a check is made to see if the Tc3 timer is timed out (R i9 ). When a result of 

jri 

5 the check at the step (R 19 ) is YES, the operation (810) of this retransmission 
5 phase terminates (Ri 8 ). On the contrary, when a result of the check at the step 
£ (Ri 9 ) is NO, the operation (810) of this retransmission phase returns to the 
step(Ri 5 ). 

20 When the result of this check (Si 7 ) is NO, a check is made to see if the 

"multi-destination retransmission data packet" has been received (R 20 ). If the 
result of this check (R 2 o) is YES, a check is made to see if the 
"multi-destination retransmission data packet" received is normal (R 2 i)- If the 
result of this check (R 2 i) is YES, the contents of the "multi-destination 

25 retransmission data packet" are stored in a memory and the Tc3 timer is 
restarted (R 22 ). When the result of this check (R 2 i) is NO, a retransmission 
request data list is prepared and the Tc3 timer is restarted (R 23 ). When the 
result of the check (R 20 ) is NO, or when the operations in the step R 22 or R 23 are 
completed, a check is made to see if the "multi-destination retransmission end 
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packet" has been received (R 24 )- When the result of this check (R 24 ) is YES, 
the operation (^10) of the retransmission phase is performed again (Rio), and 
when the result of the check (R 2 o) is NO, the receiving side goes back to step 
(Rn). 

5 Fig. 26 is a flowchart illustrating operations at the sending side in the 

acknowledgement phase. 

In this instance, when the operation (^2) of the acknowledgement phase 
is started (S 2 i), Ts3 timer and Ts6 timer are started and the "acknowledgement 
start packet" is transmitted (S 22 ), then a check is made to see if all the 

10 acknowledgement lists have been completely confirmed (S 23 ). If the result of 
S this check at the step (S 23 ) is YES, the operation of the acknowledgement phase 
fi ends (S 25 ) after the "acknowledgement end packet " is transmitted (S 24 ). 
P When the result of the check (S 23 ) is NO, a check is made to see if the Ts3 timer 
H is timed out (S 26 ). When the result of the check (S 26 ) is YES, the sending 
1J side decides that the completion of transmittal becomes failure for the 
I non-received member for whom the acknowledgement has not completed on 
5 the acknowledgement-lists (S 27 ), and then the "acknowledgement packet" is 

11 sent out (S 24 ) and the operation of the acknowledgement phase ends (S 25 ). 
When a result of the check at the step (S 26 ) is NO, a check is made to see if an 

20 "acknowledgement answer packet" is received (S 28 ). When a result of the check 
at the step (S 28 ) is YES, the sending side decides that the completion of 
transmittal is successful for the received member on the acknowledgement-lists 
(S 29 ). After completion of the operation of the step (S 29 ) or when a result of the 
check at the step (S 28 ) is NO, a check is made to see if Ts6 timer is timed out 

25 (S 30 ). When the result of this check (S 30 ) is YES, the "acknowledgement 
packet" is sent out and the Ts6 timer is restarted (S 30 ). When a result of the 
check at the step (S 30 ) is NO, or when the operation at the step (S 30 ) is 
completed, the sending side returns to step (S 23 ). 

Fig.27 is a flowchart illustrating operation at the receiving side in the 
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acknowledgement phase. In this instant, when the operation (JK20) of the 
acknowledgement phase is started (R13X Tc3 timer is restarted (R25) and a 
check is made to see if the "acknowledgement start packet" has received (R26)* 
When a result of this check at the step (R 2 6) is YES, the "acknowledgement 
5 answer packet is transmitted (R27), with which the operation (^20) is 
terminated (R28). When a result of this check at the step (R 2 e) is NO, a check is 
made to see if Tc3 timer is timed out (R29). When a result of this check at the 
step (R29) is NO, the operation is returned to the step (R26). When a result of 
this check at the step (R29) is YES, the operation (^20) is terminated (R28). 
10 Fig. 30 is an actual embodiment of the present invention, in which a 

5 request numeral 10 is a hub-station used as the sending side, 11a host-server 
flj (e.g. : a personal computer) of the client, which is connected to the hub-station 
p 10 via a leased line 12; 20 a communication satellite; 31 a time-division 
!r5 -multiple path (e.g.: 2 mega bit/sec at most) from the hub-station 10 to the 
communication satellite 20; 32 and 33 each a time-division-multiple-access 
® path (e.g.: 150 kilo-bit/sec); 40-1,40-2 and 40-3 each a very small terrestrial 
g station; 41-1, 41-2and 41-3 each In Door Unit (IDU); 42-1, 42-2,42-3 ,42-4and 
M 42-5 each a client device (e.g.: a personal computer) of each client; 43-1 and 

43-2 each a LAN (Local Area Network). 
20 In a two-way communication service by the use of a communication 

satellite exemplified in Fig. 30, unlike in a one-way satellite communication 
service, the effective use (by shortening the "retransmission request packet") of 
the up-link circuit (remote site -^hub station) leads to reduction of the network 
cost, and hence it is very important; therefore, this invention method which 
25 permits reduction of the "retransmission request packet" is suitable for use in 
such a two-way communication service. 

As described above in detail, this invention provides such merits as 
listed-up below. 

(1) In the conventional MFTP system in which a data error is expressed 
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by a bit map, even if only one DTU is erroneous, it is necessary to send a 
retransmission request packet composed of a bit map (which usually has a size 
of one MTU (=1500 bytes) corresponding to one block. In contrast to this, 
according to the multicast file transmission method of the present invention 
5 (MSAT system), since an error is expressed by the "offset position (4)"+"data 
length (4)" (a total of 8 bytes), it is possible, for a single error and successive 
errors, to request its retransmission with a small number of bytes. 

(2) Recently communication circuits, including a satellite 
communication circuit, have moved up in quality and are substantially 

10 error-free or their failure is very rare, in which case the MSAT system 
3 according to the present invention permits transmission of the retransmission 
Si request packet more efficiently than the conventional MFTP system. Fig. 29 
r; shows the sum total of sizes of retransmission request packets at one receiving 
J} station with respect to the transmission file size and circuit bit error rate 
15 indicated, hi practice, errors in the satellite communication circuit often occur 
W on a block-wise basis; according to the MSAT system, when errors occur in 
O blocks consecutively, it is possible to make the retransmission request for a 
u plurality of "file data packets" with a single "offset position (4)" + "data length 
(4)", providing increased efficiency in the transmission of the retransmission 
20 request packet. 

(3) In this invention method, there is apprehension that the number of 
"retransmission request packets" increases when the line quality is extremely 
low, but it is possible to reduce such a risk by such a limitation that no 
retransmission request is made when the number of error packets is larger than 

25 a predetermined value. 
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